By Ravi Srinivasan
Integrated System Design
April 2, 2002 (12:22 p.m. EST)

Platform-based designs are emerging as the dominant methodology for rapid development and deployment of system-on-chip devices. In this methodology, SoC design teams integrate and verify block designs gathered from multiple sources into an existing baseline design, a task that represents one of the most important jobs in the development process. Usually, problems that arise in the integration effort occur late in the development cycle and are often costly to budget and schedule, so full integration testing should be employed from the earliest stages of the design.

This article introduces a qualification environment that provides full-chip integration testing using a combination of preexisting and estimated design information to identify and resolve integration challenges early in the design cycle. This approach enables developers to take advantage of the true benefits of platform-based design.

Rapid design derivatives of a modern SoC can be deployed to multiple projects if the SoC is developed using a platform-based (that is, baseline) design. At the heart of a platform-based SoC design are block-based subsystems, such as a microprocessor, DSP and I/O subsystems (Fig. 1). A DSP subsystem, for example, contains a signal processor core, configurable caches, memory interface, DMA, bridge logic and set of standards-based peripherals. In effect, these subsystems are complex, small "chips" in their own right, and may be used and reused in multiple chip implementations.

Understandably, the task of full-chip integration has grown in complexity and contributes to the major bottlenecks in SoC development. Today, the designer not only works with multiple system definitions for each block-based subsystem, but also with multiple design views and varying degrees of design maturity. This leads to several integration-related challenges such as resolving pin mismatches between block- and chip-level views, resolving inconsistent DRC/LVS decks vs. a foundry technology rule file and remapping hard macros from multiple sources to a reference-layer map file for consistent GDSII views. Other problems that crop up include fixing signal integrity issues caused by over-the-macro routing and finishing the chip with limited routing resources.

To overcome potential integration problems, SoC design teams should analyze the block designs against the chip-level physical-design constraints, evaluate the physical-design views with a target technology process and qualify the RTL design views with appropriate block-level design constraints. This full-chip, "context-based" approach should also be consistent with the overall SoC development process. The requirements of a context-based qualification process are described below.

Semiconductor companies have made valuable progress in building "context-independent" qualification processes. Their efforts have resulted in, among other things, templates to develop new block designs, checklists to evaluate preexisting block designs and guidelines to reuse those designs in multiple SoC projects. However, such attempts have met with limited success because the checklists, templates and guidelines are often subjective, and the qualification process is difficult to incorporate into the SoC development flow. Also, all design views (for example, RTL, GDSII) for the entire chip must be available just to evaluate the use of a block design in the specific full-chip implementation.

A qualification process should provide a framework for evaluating block designs using chip-level design constraints, and it should be consistent with the SoC development process. The context-based qualification activities should include an early bring-up of full-chip design with available preexisting and estimated design information, RTL design rule checks, preliminary floor planning and synthesis, and full-chip analysis with target chip-level design constraints like timing, power, area and test. The earlier all this is accomplished, the sooner problems can be detected and fixed.

For example, when a preexisting block design is targeted to deep-submicron (0.18-micron and below) technologies, the chip-level constraints of macro/pin placement, available routing resources and minimum routing widths play a greater role in the resulting functionality of the subsystem. These effects only increase the likelihood of potential chip failure. By addressing these types of problems early in the development process, the SoC design team can lower the development cost by avoiding respins, achieve desired quality of results (that is, meet target goals) and mitigate the risk of missing the schedule.

Parallel activities
The SoC design process involves two parallel sets of activities (Fig. 2): design implementation (closure) and design analysis (integrity). For each implementation process step there is a corresponding analysis activity that determines the integrity of the full-chip design. For example, when coding RTL, the designer performs RTL design rule checks to determine the compliance to design reuse guidelines. And when performing RTL synthesis, the designer performs preliminary static timing analysis to determine the timing exceptions and timing budgets.

RTL "Lint" (design rule check) is an essential process to qualify preexisting soft macros or newly developed RTL code. However, this process is not sufficient to qualify the block designs, which tend to be a combination of soft and hard macros.

As an estimate, in a platform-based design methodology, more than two-thirds of the chip may be available in the form of preexisting RTL and GDSII views, with the remainder including newly acquired intellectual-property blocks (hard or soft macros) and new application-specific logic design (yet-to-be-created RTL).

The early full-chip qualification environment (as seen in Fig. 2) gives the design team an ability to bring up a full-chip (SoC) design for evaluation and analysis prior to completion of the RTL code and GDSII stream-out for the new designs (that is, the remaining third of the chip). The process of analyzing the full-chip design with estimated information is referred to as the "pipe cleaner" phase. In this phase, the SoC design team evaluates the block designs against chip-level constraints and identifies potential integration challenges early in the development process. The design team then migrates to a "predictable" process to integrate and analyze all of the design views of the remaining third of the chip as they are completed and become available.

SoC design teams (integrators) and block design teams (providers) can adopt an early full-chip qualification process to evaluate new designs using the appropriate chip-level contexts. The block design team can qualify the hard macro within the subsystem and deliver design views that are consistent with the SoC integration environment. The SoC design team can qualify the subsystem with the rest of the chip and recommend relevant feedback such as performance, aspect ratios and test coverage from a technology-specific integration effort. This approach also reduces the burden on the block design teams of supporting potentially multiple integration efforts.

Full-chip qualification
The early full-chip SoC qualification environment is described next as used in a context-based process. Following the steps delineated in this process, designers can build a new block design with estimated information, evaluate this design with chip-level design constraints and highlight any potential integration-related bottlenecks early in the SoC development process. The designers can modify the design views (RTL, GDSII) that are still in development and take corrective actions to resolve those bottlenecks. For example, they can add pins to the application logic, repartition the hierarchy of the logic design and even modify the layout and stream out new GDSII using an appropriate reference-layer map file.

The full-chip qualification process begins by creating a table, or text, file for each block design prior to RTL coding using its microarchitecture definition.

The table file specifies in a tabular format the I/O and clock pin description, the functionality (combinatorial, asynchronous, synchronous), the estimated gate count and the estimated timing as a fraction of the clock period. Next, the designer can process these table files in order to generate timing views in Quick Timing Model and physical-design views in a gate-level netlist (Qgates), then incorporate these views with the rest of the preexisting designs.

After preliminary floor planning and synthesis, the designer can analyze, validate and qualify the timing and floor plan using PrimeTime and Chip Architect, respectively. The designer can then refine and update the content of the table files to resolve any chip-level design conflicts. Finally, with this updated information, designers can generate block-level timing constraints for the initial synthesis effort.

The benefits to this approach are that SoC design teams can qualify all of the block designs using chip-level design constraints ("in-context") and can utilize the same integration environment for the production development effort. For example, upon completion of block design RTL for soft blocks and timing-model/GDSII generation for hard blocks, the estimated timing and physical views can be replaced with these accurate models and analyzed for design integrity, chip-level sign-off and tapeout.

Using the methodology presented, and with a combination of final and estimated design information, SoC design teams can qualify block designs in a full-chip environment, identify potential bottlenecks early in the design cycle and implement the SoC design to achieve the targeted goals on a predictable schedule.

---

Practice manager Ravi Srinivasan is responsible for implementation service offerings within Synopsys Professional Services (Mountain View, Calif.). Srinivasan holds an MBA degree from Purdue University and an MSEE degree from Southern Methodist University.

http://www.isdmag.com

Copyright © 2002 CMP Media LLC
4/1/02, Issue # 14154, page 42.

Related Stories:

PDF Download Part 1

PDF Download Part 2

PDF Download Part 3